Today there are two major approaches for booting a PC. The first approach (the “legacy approach”) originated with IBM in the 1980s, while a more modern approach (the “EFI/UEFI approach”) was initially developed by Intel Corporation in 1999 and was later enhanced by others. These two approaches are not necessary compatible as these standards use a different model to launch the operating system and initialize hardware resources.
Operating systems are generally designed to be booted using either the legacy approach or the EFI/UEFI approach for booting. Typically, older operating systems (“legacy operating systems”) expect to be booted using the legacy approach and do not support being booted using the EFI/UEFI approach. On the other hand, newer operating systems (“UEFI operating systems”) typically expect to be booted using the EFI/UEFI approach and do not support being booted using the legacy approach. This presents a challenge for firmware manufacturers as firmware needs to support not only newer operating systems which generally expect to be booted using the EFI/UEFI approach, but also older operating systems which generally expect to be booted using the legacy approach.
Certain optional or peripheral devices may be coupled or plugged into a PC to provide additional capabilities to the PC. Some less-complex peripheral devices (such as a mouse or keyboard) may be directly supported by the firmware. However, more complex devices, such as a network card or video card, may be supported by executable code, provided by the manufacturer of the device, which may be called or referenced by the firmware.
With respect to video cards, there are generally two approaches for making the executable code provided by the manufacturer of the video card accessible to the firmware of the PC. According to a first approach, a third party option ROM and a third party UEFI video driver are used to support the two classes of operating systems (legacy operating systems and UEFI operating systems). In a second approach, a third party option ROM is provided and a generic UEFI Video Driver uses the real mode services provided by the option ROM to create an instance of the UEFI Graphics Output protocol.
Both of these approaches for supporting legacy video suffer from disadvantages. The first approach is slow, especially on systems which must boot legacy and UEFI operating systems, since, in the course of booting, the system firmware may have to load first the option ROM and then load the UEFI driver, perhaps more than once. The first approach is also larger in size than is desirable, as each of the two drivers contain roughly the same level of executable code, and, in many cases, must be placed inside of non-volatile storage (flash, EEPROM, etc.) on a plug-in card or on the system motherboard. In either case, this could cause the cost of the product to rise. Another disadvantage to the first approach is that it is difficult to maintain, as bug fixes and feature updates must be made in both the option ROM and the UEFI driver.
The second approach for making manufacturer-provided executable code available to the firmware also exhibits problems with size and speed. The option ROM is run in 16-bit real mode, which is a slower and more constrained mode of x86 CPUs. The UEFI driver is run in either 32-bit or 64-bit protected mode, which is a faster mode, but efficient access to the graphics frame buffer used for high-performance graphics is not possible. Also, the option ROMs can only execute in a relatively small area of memory (roughly from 768K to 1 MB). Finally, as system firmware makes the transition to UEFI, the number of third party vendors who will either produce or optimize for performance their option ROMs will dwindle over time.
Discussion in this section is meant to provide an understanding of prior approaches to the reader as they relate to embodiments of the invention. However, the disadvantages of prior approaches discussed in this section are not meant to be an admission that such disadvantages were publicly known. Consequently, recognition of the disadvantages of the prior art discussed herein is not meant to be construed as being within the prior art simply by virtue of its inclusion in this section alone.